Page 1 of ? 



(19) 



J 



(12) 



(43) VerOffenllichungstag: 

24.06.1998 Patentblatt 1998/26 

(21) Anmeldenummer: 97122098.3 

(22) Anmeldetag: 15.12.1997 



EuropSisches Patentamt 
European Patent Office 
Office europden des brevets (11) EP 0 849 666 A2 

EUROPAISCHE PATENTANMELDUNG 

(51) Into. 6 : G06F9/44 



(84) Benannte Vertragsstaaten: 


(71) Anmelder: 


AT BE CH DEDKESF1FRGBGR IE IT U LU MC 


SIEMENS AKT1ENGESELLSCHAFT 


NLPTSE 


80333 MOnchen (DE) 


Benannte Erstreckungsstaaten: 


(72) Erfinder: 


ALLTLVMKROSI 




• Reich, Matthias 


(30) Prioritat: 20.12.1996 DE 19653557 


81737 MOnchen (DE) 


• Seldler, Steffen 




39576 Stendal (DE) 



(54) Verfahren zum Instantiieren einer versionsbehafteten Klasse 

(57) Das Verfahren ermoglicht das Updaten von 
Objekten in einem Netzwerk zur Laufzeit des Systems. 
Dabei werden versionsbehaftet Objekte, v.a. Software- 
Agenten, instantfiert. Es wird unterschieden zwischen 
dem versionsbehafteten Instantiieren eines Objekts, 
dem Update versionsbehafteter Kiassen und dem 
Update der Plattform, die Betriebssoflware fur den Soft- 
ware-Agenten bereitsteilt. 

Anwendungen des Verfahrens sind Internet. Netz- 
management. Java und allgemein vernetzte und/cder 
verteitte Systeme. 
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Beschreibung 



Die Erfindung betrffft ein Verfahren zum Instantiie- 
ren einer in einer objektorientierten Programmierspra- 
chedefinierten versionsbehafteten Wasse. 

Ein (Software-)Agentensystem besteht im weserrtii- 
chen aus rwei Komponenten, der Agent enplattform und 
dern Agenten selbst Oftmals ist zusatzlich als dritte 
Komponente ein Monitoring- und Administrations-Tool 
vorhanden. Ein Agent (tm Internet auch Robot Wande- 
rer oder Spider genannt) ist ein Programm, das mit den 
Rechten eines bestimmten Benutzers ausgestattet, 
eine von der konkreten zu erfullenden Funktion abhan- 
gige Zeit unbeaufsichtigt existiert und sich wahrend die- 
ser Zeit mit anderen Agenten treffen und mit ihnen 
zusammenarbeiten kann. Damit ein Agent nicht nach 
Virenart Rechnersysteme lahmlegt muB er sich "aus- 
weisen" und darf nur eine endliche Lebensdauer besit- 
zen. 

Generell werden zwei Arten von Agenten unter- 
schieden. Ein stationarer Agent wird vom Programman- 
fang bis zu seinem Ende nur von einem Rechner 
ausgefuhrt Ein mobiler Agent dagegen wird zu ver- 
schiedenen Zeiten seines LebenszyWus von verschie- 
denen Rechnern ausgefuhrt. Auf den Rechnern, die fur 
den Agenten erreichbar sein sollen. muS eine Agenten- 
plattform existieren. Diese Agentenplattform stellt dem 
Agent u.a. Dienste fOr Migration. (kDntroIIierten) 
Systemzugriff und Nachrichtenversand und Nachrich- 
tenempfang zur VerfQgung. Das Monitoring- und Admi- 
nistrations-Tool ermoglicht den manuellen Start von 
Agenten. den Oberblick Qber von Agenten gesammelte 
Daten und die Anzeige anderer, das Agentensystem 
betreffende Informationen. 

Ein System mobiler Agenten kann wahrend seiner 
Laufzeit auf viele Rechner innerhalb eines Netzwerkes 
verteift sein. Dazu ist sowohl auf jedem (Knoten-) Rech- 
ner in dem Netzwerk eine Plattform notwendig, als auch 
kOnnen sich Agenten, Datenstrukturen und Nachrich- 
tenobjekte von Rechner zu Rechner bewegen. Werden 
nun im Laufe des SoftwarelebenszyHus Fehler in einem 
dieser (Teil-)Programme festgestellt oder sollen aus 
anderen GrOnden Teile der Software verandert werden 
(z.B. Verbesserung von Algorithmen, Anpassung an 
veranderte Umgebung, begrenzt auch Funktionsande- 
njng). so kann u.U. ein Beenden und nach den entspre- 
chenden Veranderungen ein anschlieGender Neustart 
des gesamten Systems nOtig sein. 

Das der Erfindung zugrundeliegende Problem 
besteht darin, auch wahrend der Laufzeit des Software- 
systems versionsbehaftet Anderungen an Systemteilen 
vornehmen zu konnen, wobei sich diese Anderungen 
nach und nach im gesamten System durchsetzen sol- 
len. 

Das Problem wird durch das Verfahren gemaB den 
Merkmalen des Patentanspruchs 1 gelost. 

Das erfindungsgemaGe Verfahren ermoglicht es 
also, auch wahrend der Laufzeit Anderungen an 



Systemteilen vorzunehmen, wobei sich diese Anderun- 
gen dann schrittweise im gesamten System ausbreiten. 
Eine Urrterscheidung zwischen den veranderten Pro- 
grammtenen wird moglich. indem eine Versionsverwal - 

5 tung in das Konzept des dynamischen Updates 
integriert wird. So ist es beispielsweise moglich. bei ver- 
teilter SoftwareentwicWung ublicherweise verwendete 
Versionsverwartungssysteme und die somit vorhande- 
nen Informationen Qber die verschiedenen Versionen zu 

jo integrieren. 

Als Programmiersprache zur Implementierung des 
mobilen Agentensystems kann Java verwendet werden. 
Genauso ist es mOglich. jede andere Programmierspra- 
che zu verwenden. die ein dynamisches Laden von 

is Wassen zur Verfugung stelrL Auch diesbezOgliche 
Erwerterungen von Programmiersprachen wie bei- 
spielsweise C++ sind denkbar. 

GemaB den gestellten Anforderungen sollen die 
Wassen fur die Plattform. die Agenten und verschie- 

20 dene von ihnen referenzierte Objekte (u.a Datenstruk- 
turen und Nachrichten) versionierbar sein. Urtter 
Plattform ist beispielsweise ein beliebiges Rechnersy- 
stem zu verstehen. das als Knoten im Netzwerk agieren 
kann und ein Programminterface (Betriebssoflware) fur 

25 den (Software-)Agenten schaffL 

Werden an nichtfehlerhaften Klassen Anderungen 
z.B. hinsichtlich der Effizienzdurchgefuhrt. so sollen die 
alten Versionen der Objekte ihre Arbeit wie vorgesehen 
beenden konnen. Damit besteht die Moglichkeit der 

so gleichzeitigen Existenz von Objekten verschiedener 
Versionen nebeneinander. die wiederum Objekte ver- 
schiedener Versionen referenzieren. Es ist also notwen- 
dig. zumindest bis zum "Aussterben" aller Objekte einer 
Version, sowie der sie referenzierenden Objekte. die 

35 alten Klassendefinitionen parallel zu neuen Wassende- 
finitonen bereitzustellen. Bei fehlerhaften Versionen 
dagegen kann die Moglichkeit geschaffen werden. nach 
dem Einspielen der neuen Klasse alle Objekte der arten 
Version schnellstmoglich zu vernichten. 

40 Zur Auswahl der jeweils "passenden" Version der 
benotigten Klasse ist ein eigener Klassenlademecha- 
nismus (Classloader) notwendig. 

Das erfindungsgemaGe Verfahren zum versionsbe- 
hafteten dynamischen Update von Klassen eines mobi- 

45 len Agentensystems umfaBt das. Update der Plattform. 
das Update versionsbehafteter Klassen und die Instan- 
tiierung eines Objekts einer versionsbehafteten Klasse. 

WeiterbiWungen des erfindungsgemaQen Verfah- 
rens ergeben sich aus den abhangigen AnsprOchen. 

so Es zeigen 

Fig.1 ein Blockdiagramm. das das Update einer 

Plattform darstellt. 
Fig.2 ein Blockdiagramm, das das Update versio- 
55 nierbarer Klassen darstellt 

Fig .3 ein Blockdiagramm, das die Instantiierung 

eines Objekts einer versionierbaren Klasse 

darstellt. 
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In Fig.1 wird die MOglichkeit dargestellt. sequentiell 
das Update aller Plattformen im System zu veranlas- 
sen. Dabei ist es wichtig. daB den Agenten ausreichend 
Zeit bleibt, eine Ausweichmoglichkeit in Form einer 
benachbarten Plattform zu find en. Damit auch bei 
neuen Plattformversionen alle von anderen Objekten 
genutrte Methoden der jeweiligen Plattform vorhanden 
sind. ist es vorteilhaft die Programmierschnittsteiie der 
Plattform, d.h. die Signaturen der von anderen Objekten 
nutzbaren Methoden. exakt festzulegen. Bei einer 
Implementierung in Java geschieht dies durch die Defi- 
nition eines 'Interface*, das jede Version der Plattform 
implementiert. 

Die zu ersetzende Plattform bekommt ein Signal 
zum Shutdown (Schritt 1a). Ein festgelegtes Zeitinter- 
vall. dessen Lange beispielsweise mit dem Shutdown- 
Signal ubermittert wird, legt die Wartezeit bis zum tat- 
sachlichen Herurrterfahren der Plattform fest Es ist vor- 
teilhaft, den lokal auf dieser herunterzufahrenden 
Plattform existierenden Agenten den bevorstehenden 
Shutdown mitzuteilen (Schritt 1b). Alle auf dieser Platt- 
form neu ankommenden Agenten werden abgewiesen, 
wohingegen ein Abwandern von Agenten (Schritt 1c) 
zugelassen ist Nach AWauf des Zeitintervalls bis zum 
Herurrterfahren der Plattform (Schritt 1d) werden die 
lokal auf der Plattform noch existierenden Agenten 
beendet (Schritt 1e). Besonders wichtige Agenten kon- 
nen dabei zumindest teilweise gesichert werden, so 
daB sie nach dem Update der Plattform erneut gestartet 
werden konnen. Weiterhin werden die Daten gesichert 
die den Shutdown der Plattform Qberieben sollen, bei- 
spielsweise Daten des Blackboards oder Zahler fur die 
Benennung von Nachrichten. SchlieBlich wird das 
Update der Plattform durchgefuhrt (Schritt 1f). 

In Fig.2 ist ein Blockdiagramm zum Update versio- 
nierbarer Klassen dargestellt. Nach dem Einspielen 
einer neuen Version einer Klassendefinition (Schritt 2a) 
werden alle Classfileserver Qber die Existenz diese 
neuen Klassenversion informiert (Schritt 2b). Wird spa- 
ter ein Agent dieser Klasse neu erzeugt und seine Klas- 
sendefinition beim Classfileserver ohne Angabe einer 
vorausgesetzten Version angefordert, so wird stets die 
aktuellste Version geliefert und instantiiert. Damit ist die 
Aktualitat des Gesamtsystems gewahrleistet Soil die 
arte Version des Agenten zerstort werden (Schritt 2e). 
weil sie beispielsweise fen I er haft ist so muB an alle 
Agenten dieser Version ein Rundruf gesendet werden, 
sich selbst zu beenden (Schritt 2f). Dabei ist zu prufen, 
ob trotz eventuell neuer Datenstrukturen die Daten der 
atten Agenten gesichert werden sollen, urn von denen 
einer neuen Version genutzt werden zu konnen. Im 
Falle einfacher Funktionsanderung oder Funktionser- 
weiterung eines Agenten sterben die alten Agenten 
"natOrlich" aus. da fehlerfreie Programme ihre Arbeit 
wie vorgesehen beenden kOnnen. 

Wie oben erwahnt. gibt es Klassen, die keine 
abstrakte Beschreibung von Agenten oder Plattformen 
darstellen. Diese Klassen stehen beispielsweise fur 



Datenstrukturen. Es ist moglich. daB mit Funktionsan- 
derung eines Agenten auch die Anderung der von ihm 
genutzten Datenstruktur bedingt ist Ebenso wie bei den 
Agentenkiassen werden auch bei Einspielen einer 

5 neuen Klasse anderen Typs die Class-Server per 
Broadcast informiert (Schritt 2b). Wird spater ein Objekt 
dieser. Klasse ohne Vorgabe einer bestimmten Version 
instantiiert, so wird stets die aktuellste Version genutzt. 
Damit wird gewahrleistet daB Objekten (z.B. Agenten), 

w die nicht auf eine bestimmte Version der von ihnen refe- 
renzierten Objekte angewiesen sind, stets die aktuellste 
Version einer Klassendefinition zur Verf ugung stent Die 
Agenten selbst (eventuell aucrualle anderen -Objekte. 
die versionierte Objekte referenzieren) fuhren eine Ver- 

15 sionstabelle mit sich, in der zu jedem bereits referen- 
zierten (versionierbaren) Objekt die Version einer 
Klasse verzeichnet ist Der Class-Loader des Agenten 
fordert anhand dieser Versionstabeile die Klassendefi- 
nition der angegebenen Version an. 

20 Soil, wie in Fig.2 dargestellt, eine neue Klassenver- 
sion eingespielt werden, so werden in Schritt 2b die 
Classfileserver von der Existenz dieser neuen Klassen- 
version per Broadcast urrterrichtet Die einzelnen 
Classfileserver fordern von der Administrationsplattform 

25 die neue Klassenversion an, wenn sie diese Information 
benetigen (on demand, Schritt 2c). 

Ist die neue Klassenversion keine AgentenWasse, 
so werden die Plattformen Ober die neue Klassenver- 
sion per Broadcast unterrichtet (Schritte 2d, 2h) und die 

30 Classfileserver holen sich die neue Klassendefinition 
beim erstmaligen Erzeugen eines Objekts einer Klasse 
(Schritt 2g). 

Ist die neue Klassenversion eine AgentenWasse 
und soli die arte Klassenversion weiterhin zur Verf Qgung 

35 gesteltt werden (Schritte 2d. 2e), so werden alle Platt- 
formen Ober die neue Klassenversion per Broadcast 
urrterrichtet (Schritt 2h), und die jeweilige Plattform holt 
sich bei erstmaiiger Instantiierung des der neuen Klas- 
sendefinition entsprechenden Objektes diese neue 

40 Klassendefinition vom Classfileserver (Schritt 2g). 

Handett es sich bei der neuen Klassenversion urn 
eine AgentenWasse und soil die aite Version des Agen- 
ten sterben (Schritte 2d, 2e), so werden alle Plattformen 
uber die neue Klassenversion des Agenten per Broad - 

45 cast unterrichtet und das Sterben der atten Agenten 
eingeleitet (Schritt 2f), wobei die Agentendaten ggf. 
gesichert werden. Erzeugt die jeweilige Plattform das 
erste ma! einen Agenten mit der neuen Klassenversion, 
so holt sich die Plattform die Klassendefinition vom 

so Classfileserver (Schritt 2g). 

Zur Verwaftung, d.h. zum Einspielen neuer und 
zum LOschen after KJassendefinitionen, existieren 
einige wenige Classfileserver im Netz. denen die Klas- 
sendefinition als Datei innerhalb einer bestimmten Ver- 

55 zeichnisstruktur vorliegt Soil eine neue Version einer 
Klasse ins System eingebracht werden, so wird die ent- 
sprechende Datei vom Administrator im Einspierver- 
zeichnis eines der Classfileserver abgelegt Dabei ist es 
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vorteflhaft. dem auf diesem Rechner laufenden Ein- 
spieftod (verwendbar im Rahmen eines Administrati- 
ons- und Monitormg-Prograrnrns) nur den Namen der 
abgelegten Wassendatei anzugeben. Dieses Tool 
erzeugt aus der angegebenen Klassendatei die errt- 5 
sprechende Klasseninstanz, von welcher ein Objekt der 
Klasse instantfiert wird. Wird. wie im Beispiel, von einer 
Implement* erung in Java ausgegangen. so kann die in 
dem jeweiiigen Objekt verankerte Versionsnummer 
durch den Aufruf der Methode getVersionO. die die von 10 
der Versionsverwaltung der Programmierumgebung in 
den Guelltext integrierte Version fiefert. ermittett wer- 
den. Den realert Namen der Klasse erfahrt das Tool- : T 
Ober die von Java fur jede Klasse bereitgestellte 
Methode getNameO der Klasseninstanz. Nach Ober- 75 
prufung der bereits vomandenen Versionen (keine alte 
Oder bereits vorhandene Version einspielen!) wird die 
Datei in das entsprechende Verzeichnis kopiert, wobei 
der neue Dateiname sowohl den Klassennamen als 
auch die Versionsnummer enthalt Dadurch werden die 20 
(durch die von der bei der SoftwareerrtwicWung einge- 
setzte Versionsverwaltung einmalig vergebenen) Versi- 
onsnummern automatisch ubernommen und somit 
Nutzfehler reduziert Ein weiterer Vorteil der in der 
Klasse sefbst verankerten Version ist die MOglichkeit 25 
auch spater ohne Wissen des Dateiriamens oder der im 
System verwendeten Versionstabellen die Version 
eines Objektes versionierbarer Klasse ermitteln zu kon- 
nen. WeHerhin kommt dem Tool die Aufgabe zu. die 
Class-Server von der Existenz neuer Klassendefinrtio- 30 
nen per Broadcast zu unterrichten. 

Eine Weiterbildung des erfindungsgemaBen Ver- 
fahrens besteht darin. nur auf jeweils einem der Classf i- 
leserver die neuen Wassendefinitionen einzuspieten. 
Die Information Ober neue Wassendefinitionen ist aber 35 
alien im Netz vomandenen Classf ileservem gleicher- 
maBen zuganglich zu machen, was einen Abgleich 
erforderlich macht Nach dem Einspielen einer neuen 
Version einer Klasse wird alien Classfileservern im Netz 
eine Information uber die neue Version der Klasse und 40 
den diese Klasse zur Verfugung stehenden Classfile- 
servern gesendet Die Anforderung dieser Klassendef i- 
nition bleibt dem einzelnen Classfileserver selbst 
uberlassen. Durch diesen Anforderungsmechanismus 
wird gewahrleistet. daB. sobald ein Classfileserver von 45 
einer neuen Klassendefinition erfahrt, diese durch inn 
angefordert werden kann. 

In Fig.3 wird ein Blockdiagramm zur Instantiierung 
einer Objekts einer versionierbaren Klasse dargestellt. 
In Schritt 3a wird davon ausgegangen, daB ein Objekt so 
einer versionierbaren Klasse instantiiert werden soil. 
Wird keine bestimmte Version der Klassendefinition 
gefordert (Schritt 3b), so wird standardmaBig die neue- 
ste Version der Klassendefinition zur Instantiierung des 
Objekts verwendet (Schritt 3c). Ist diese neueste Klas- 55 
sendefinition bereits lokal auf der Plattform verfugbar 
(Schritt 3d), so wird das Objekt instantiiert (Schritt 3j), 
sonst muB die aktuelle Klassendefinition vom bekann- 
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ten ClassfDeserver geholt werden (Schritt 3i) und 
danach wird das Objekt instantiiert (Schritt 3j). 

Ist hingegen eine bestimmte Version der Klassen- 
definition zur Instantiierung eines Objekts gefordert 
(Schritt 3b). so wird. falls die geforderte Klassendefini- 
tion lokal auf der Plattform verfugbar ist (Schritt 3e). das 
Objekt instantiiert (Schritt 3j). ansonsten nach der 
geforderten Klassendefinition beispieisweise nachein- 
ander auf einer Vorgangerplattform. einer Ursprungs- 
plattform des Agenten und schlieBlich auf den 
aassfileserver gesucht (Schritt 3f). Wird die geforderte 
Klassendefinition nicht gefunden (Schritt 3g), so kann 
das Objekt nicht instantiiert werden (Schritt 3h) f anson- 
sten wird das Objekt entsprechend der zu benutzenden 
Version der Klassendefinition instantiiert (Schritt 3j). 

Aufgrund der Broadcasts an die Classfileserver 
sind diesen jeweils die aktuellen Versionen der Klassen- 
def initionen bekannt. Die Nachricht. die den Agenten 
ubertragt wird die Version des Agenten vorangesteltt 
Diese Version ist auf dem Ziel des Agententransports 
entweder lokal vorhanden oder muB gesucht werden. 
Die Suche nach der Klassendefinition durchlauft drei 
Stufen: 

1. Die Plattform des Agentenabsender. da der 
Agent dort moglicherweise ein Objekt dieser Klas- 
sendefinition referenzierte und die Klassendefini- 
tion daher schon im Speicher der Absender- 
Plattform gehalten wird. 0 

2. die Plattform des Agentengeburtsortes. da dort 
moglicherweise ein Objekt dieser Klassendefinition 
instantiiert wurde und schlieBlich 

3. den fur die lokale Plattform zustandigen aassfi- 
leserver. 

Afternativ dazu konnen auch andere Suchstrate- 
gien verwendet werden, z.B. kann bei Vorhandensein 
eines lokalen Classfileservers zuerst auf diesen nach 
der geforderten Klassendefinition gesucht werden, um 
Anfragen uber das Netz zu vermeiden. 

Im Ausfuhrungsbeispiel wird fur jeden Agenten ein 
eigener Class-Loader instantiiert, der eine Versionsta- 
belle der bereits referenzierten Klassen besitzt. Auch 
der Agent selbst fuhrt eine Tabelle geforderter Klassen- 
versionen mit sich. Die Versionstabelle des Clas- 
sloaders wird beim Eintreffen des Agenten mit den 
Eintragen der Versionstabelle des Agenten gefullt. Wird 
nun ein vom Agenten referenziertes Objekt instantiiert. 
so wird in der Versionstabelle des Agenten uberpruft. ob 
bereits ein Objekt dieser Klasse referenziert wurde und 
wenn ja. von welcher Version dieses Objekt ist. Wurde 
vorher noch kein Objekt dieser Klasse referenziert, d.h. 
ist diese Klasse nicht in der Versionstabelle des Agen- 
ten verzeichnet. so wird die neueste Version verwendet, 
die der Plattform durch Broadcast bekanntgegeben 
wurde. Ist diese Version noch nicht im Speicher der 
Plattform vorhanden, so wird sie gemaB obiger 
Suchstrategie gesucht und geladen. In der Versionsta- 
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belle des Agenten wird dann die Klasse und die verwen- 
dete Version der Kiassendefinition eingetragen. 

Durch den im erfindungsgemaBen Verfahren ent- 
hattenen Mechanismus der Versionsverwaftung von 
Klassendefinrlionen wird gewahrleistet. daB Agenten 
Objekte alter Klassendefinrlionen verwenden kOnnen. 
bzw. daB auch Agenten veralteter Versionen auf einer 
Plattform verarbeitet werden konnen. Da fehlerfreie ver- 
attete Versionen von Agenten bzw. Objekten allgemein 
wie vorgesehen ihre Aufgabe beenden sollen. mussen 
die aiten Klassendefinitionen eine gewisse ZeJt "aufge- 
hoben w werden. Aile bererts einmal benOtigten Klassen- 
definrlionen werden vom der Plattform im Speicher 
gehatten. Es ist daher vorteiihaft, wenn ein Mechanis- 
mus existiert. der entscheidet wann verartete Klassen- 
definrlionen verworfen werden. So kOnrrte 
beispielsweise ein Administrator manueil die verschie- 
denen Versionen mittels des Monitoring- und Admini- 
strationstools freigeben. Ein weiterer beispielhafter 
: Mechanismus zur Entscheidung Qber verahete Klassen- 
definitionen besteht darin. die einzelnen Zugrrffe auf 
Objekte versionierter Klassen mit einem Referenzzah- 
ler zu uberwachen. Existiert eine neue Version der 
Klasse und ist der Zahler der atten Version gleich 0, so 
konnte die entsprechende arte Kiassendefinition ver- 
worfen werden. Eine dritte Moglichkeit besteht darin, 
bererts bei der Einspielung einer Klasse eine Restle- 
benszeit fur diese Klasse anzugeben, die nach dem 
Auftreten einer neuen Version dieser Klasse ihre Wir- 
kung errtfaltet 

Patentanspruche 



1 - Verfahren zum instantiieren einer in einer objektori- 
entjerten Programmiersprache definierten versi- 
onsbehafteten Klasse. 

bei dem Rechner in einem Netzverbund verteilt 
angeordnet werden und von jedem dieser 
Rechner eine Plattform fur den Betrieb von 
mobiien Softwareagenten (Agenten) zur Verfu- 
gung gestellt wird, 
in folgenden Schritten: 

1a) Wenn eine bestimmte Version einer 
instantiierbaren Klasse gefordert wird, wird 
die geforderte Version benutzt und zu 1c) 
gesprungen, 

1b) sonst wird die neueste Version der 
instantiierbaren Klasse verwendet die 
Plattform untersucht. ob diese Version 
bereits lokal vorratig ist und gegebenen- 
falls zu 1d) gesprungen, sonst wird die 
Kiassendefinition der entsprechenden Ver- 
sion von einem Classfileserver geholt und 
zu 1d) gesprungen, 

1c) ist die Kiassendefinition der entspre- 
chenden Version bereits lokal vorratig, so 



wird zu 1d) gesprungen, sonst wird nach 
der Kiassendefinition gesucht und wenn 
die Kiassendefinition gefunden wird zu 1d) 
gesprungen, sonst wird die Klasse nicht 
5 instantfiert. 

1d) die Klasse wird gemaB einer zu benut- 
zender Version der Kiassendefinition 
instantiiert. 

to 2. Verfahren insbesondere nach Anspruch 1. zum 
Update versionsbehafteter Klassen, unterteilt in fol- 
gende Schritte: 

2a) Auf einer Administrationspiattform wird 
15 eine neue Version einer Klasse eingespielt, 

2b) die Information Qber die neue Version einer 
Klasse wird an Classfileserver ubermittelt 
(broadcast), 

2c) jeder einzelne Classfileserver fordert von 
20 der Adrrtinistrationsplattform die neue Klassen- 

version an, wenn er diese Information benOtigt, 
2d) wenn die neue Klasse eine AgentenWasse 
ist wird zu 2f) gesprungen, 
2e) wenn die neue Klasse keine AgentenWas- 
25 sen ist, wird die Information Ober die neue Ver- 

sion der Klasse an aile Plattformen ubermittelt 
(broadcast) und zu 2h) gesprungen. 
2f) wenn keine Agenten mit der aflen Version 
o der AgentenWasse mehr existieren sollen, 

30 dann wird zu 2g) gesprungen, sonst wird die 

Information Ober die neue Version der Klasse 
an alie Plattformen Obermitteit (broadcast) und 
zu 2h) gesprungen, 

2g) aile Plattformen werden davon unterrichtet. 
35 daB eine neue Version der AgentenWasse vor- 

liegt, und die Agenten der alten Version werden 
zerstOrt. 

2h) die Kiassendefinition der neuen Version 
der AgentenWasse wird bei erstmaliger Instan- 
40 tiierung vom Classfileserver geholt. 

3. Verfahren insbesondere nach Anspruch 1 oder 2, 
zum Update einer Plattform unterteilt in folgende 
Schritte: 



45 



50 



3a) Wenn eine Plattform upgedatet werden 
soil, werden ankommende Agenten zuruckge- 
wiesen, nur bereits auf der Plattform vorhan- 
dene Agenten dQrfen abwandern, 
3b) nach einer vorgebbaren Zeitdauer (Time- 
out) werden die noch lokal existierenden Agen- 
ten beendet und das Update fur die Plattform 
durchgefuhrt. 

Verfahren nach Anspruch 1 , 
bei dem im Schritt 1c) die Suche nach der Kiassen- 
definition nacheinander auf einer Vorgangerplatt- 
form, einer Ursprungsplattform des Agenten und 



5 



9 EP 0 849 666 A2 10 

scNieBfich auf dem Classfileserver durchgefuhrt 
wird. 

5. Verfahren nach Anspruch 2, 

bei dem zusatziich vor dem Zerstoren der Agenten s 
in Schritt 2g) vorgebbare Agentendaten gesi chert 
werden. 

6. Verfahren nach Anspruch 3. 

bei dem zusatziich zum Update der Platform in io 
Schritt 3b) vorher noch vorgebbar wichtige Agenten 
und Oaten gesichert und nach dem Update wieder- 
hergesteltt werden; " v ' - ■ ^ - - >. ^ ^ 

7. Verfahren nach Anspruch 1 .2 Oder 3 . 1 s 
bei dem eine Implementierung in einer Program- 
miersprache durchgefuhrt wird, die dynamisches 
Laden von Klassen ermoglicht 

20 



25 



o 

30 



35 



40 



45 



50 
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FIG 1 



1a- 'Shutdown' an Plattform 



1 b- • 'Shutdown' an lokale Agenten 



1c- 



ankommende Agenten abweisen, 
Abwanderung zulassen 




Nein 



1e- • lokale Agenten beenden 



1f-- 



Plattform-Update | 
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FIG 2 



ka- 



rtells Klassen- 
version einspielen 



Nein 



Nein 




Broadcast an 
Plattformen: 
neue Klassen- 
definition-Version 



-2h 



Ja 



Broadcast: 
neue Version 
und losche 
alte Version 



Broadcast an 
Classfileserver 



Abgleich der 
Classfileserver 
auf Anforderung 



-2f 





Klassen- 
definition vom 
Classfileserver • 
bei erstmaliger 
Benutzung holen 


+■ 
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FIG 3 



3a- 



Objekt einer 
versionierbaren 

Kiasse soli 
instantiiertwerden 



3c-- 



neueste Version 
nutzen 



Nein 




Klassendefinition 
vom bekannten 
Classfileserver 
holen 



-3i 



Objekt 
instantiieren 



3j 



3f- 



Klassendefinition 
suchen 





Agenten 
r (referenzie^e^den , 

bzw. zu 
instantiierenden) 
.sterben lassen. 

1 

3h 



